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ABSTRACT 


The Spacelab Data Processing Facility (SIDPF) is an integral part 
of the Space Shuttle data network for missions that involve 
attached scientific payloads. The SIDPF has developed expert 
system prototypes to aid in the performance of the quality 
assurance (QA) function of Spacelab and/or Attached Shuttle 
Payloads (ASP) processed telemetry data. The SIDPF functions 
include the capturing, quality monitoring, processing, account- 
ing, and forwarding of data from Spacelab and ASP missions to 
various user facilities. The SIDPF consists of two functional 
elements: the Spacelab Input Processing System (SIPS) and the 
Spacelab Output Processing System (SOPS) . The two expert system 
prototypes were developed to determine their feasibility and 
potential in the quality assurance of processed telemetry data. 
The SIPS expert system. Knowledge System Prototype, (KSP) , uses 
an IEM PC/AT with the ocrrmercial expert system shell OPS5+. 

Expert knowledge (from SIPS experts) emulating the duties of 
quality assurance analysts was implemented. In an interactive 
mode, a SIPS analyst responds to queries resulting in instruc- 
tions and decisions governing the reprocessing, releasing or 
further analysis/troubleshooting of data. Released data is 
forwarded for further processing cm the SOPS Sperry 1100/82. The 
data are edited, time ordered with overlapping data removed, 
deccmmutated, and quality checked before release to the user. 

The SOPS QA analysts isolate problems and select the appropriate 
action: either accept the data or request the data to be reproc- 
essed. The SOPS expert system emulates this process by utilizing 
an expert system shell, CLIPS, and the Macintosh personal 
computer. To date, these prototypes indicate potential benefi- 
cial results; e,g. , increase analyst productivity, decrease the 
burden of tedious manual analysis, provide consistent evaluations 
of data, provide concise historical records, provide training for 
new analysts, and expedite the operational training of Spacelab 
analysts. The logic implemented in the prototypes, the limita- 
tions of the personal computers utilized, and the degree of 
accessibility to input data have led to an operational configura- 
tion to be implemented on a SUN 3/160 Workstation. This config- 
uration is currently under development and on completion will 
enhance the efficiency, both in time and quality, of releasing 
Spacelab/ASP data. 
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INTRODIXTION: 


Ibe SLDPF processes payload data from Spacelab and ASP 
miss ions. The SLDPF functions include the capture, quality 
monitoring, processing, accounting, and shipping of data to 
risers. The SIDPF is ccrrposed of two functional elements: the 
SIPS and the SOPS. In SIPS, Ku-band channel 2 and/or channel 3 
data are captured onto high-density tapes (HDIS) . Pie primary 
functions of SIPS are the realtime capture, the monitoring of 
data for quality and status coordination with the Spacelab 
external interfaces such as the Spacelab Payload Operations 
Control Center (POCC) , the Mission Control Center (MOC) , and the 
Network elements. See Figure below. The data captured, includ- 
ing playback and direct access channel data, are processed to 
produce Spacelab Experiment Data Tapes (SEDIS) and/or Spacelab 
Input/Output Data Tapes (SIDTs) . To assure oarpleteness and high 
quality of SIPS processing, analysts currently perform quality 
assurance and data accounting (Qft/CA) analysis by the manual 
evaluation of Spacelab Quality and Accounting Records (SQftRs) 
a ided with information from Spaoelab reports and log s. P ie 
results of the QA analysis determine the release of SEDTs, SIDTs 
and Spacelab Quality and Accounting Tapes (SQATs) to the SOPS or 
to other users. Additional data processing is performed by the 
SOPS. Pie data are edited, time ordered with overlap removed, 
decamutated, quality checked, and shipped to users. Pie QA/T& 
analysis is a manual process of evaluating and correlating 
information from various reports and logs to determine the 
quality of the data and its status: release or reprocess. 
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Expert system applications in the Information Processing 
Division were first considered for their potential to expedite 
the SLDPF operations , in particular, the QA/C& analyst functions 
of both the SIPS and the SOPS. The extremely large volume of 
data from one mission and the short turnaround requirement for 
delivery to users often makes the QA/DA task demanding and 
tediously repetitive . The objective of the operational expert 
systems is to assist the analyst by making decisions and suggest- 
ing logical analysis paths based on given data quality informa- 
tion. The strategy formulated to accomplish the prototypes was 
to use ccinnercial expert system shells, code the QA/DA knowledge 
bases within the shells and implement them on personal compu- 
ters. The SIPS KSP uses the 0PS5+ Development System with a 
C language interface installed on an IBM PC/AT. The SOPS Expert 
System (ES) prototype was implemented with the expert system 
building tool CLIPS and an in-house-written interface on an Apple 
Macintosh. 

SIPS KSP: 

The SIPS KSP is designed to emulate the performance of 
experienced SIPS QA/DA analysts in the evaluation of Spacelab 
data quality and accounting information. This function is 
currently performed through the examination of data quality and 
accounting reports. 

The first task was to gather the analysis expertise of the 
QA/DA analysts to determine that this area was a practical 
application for an expert system. The scope of the initial 
effort was restricted due to the extensiveness of the application 
and the limitations of the prototype hardware and software 
configuration. Three stages of analysis were established: ini- 
tied. data evaluation, ccrparison of initial and redo processing 
run data, and data trends. Each can stand alone logically but 
need access to the data and decisions of the others. The use of 
a database to store data quality and accounting information as 
well as the decisions of each stage allows the expert system to 
be divided into independent modules which run with the available 
memory of the prototype configuration. As each module runs, 
pertinent data and decisions are written to report files from 
which database updates and printed summary reports are gener- 
ated. The code for database control, the Front End module, 
grew to include database creation and loading, data validation, 
data maintenance, data selection, expert system module selection, 
and expert system report selection. 

The rule-based expert system tool OPSSt was used to develop 
the knowledge base for the KSP. The knowledge elements (rules) 
are in the form "IF <oondition(s)> THEN <action(s)>." The KSP 
Stage 1: Initial Data Evaluation knowledge base consists of 201 
rules; Stage 2: Comparison of Initial and Redo Processing Runs, 
130 rules. Completion of Stage 3: Data Trends has been deferred 
to direct the use of resources to the operational system require- 
ments definition. 
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-me Front End interfaces with the user in the form of 
selection and input screens. Required responses are limited to 
ane-kevstrdke if default values are selected. Page forward and 
backward options are provided. Data inputAiewing screens are 
provided to allow input and data maintenance. Stage 1 interfaces 
^rth the user in the form of a running dialog. It is initiated 
by loading and initializing the evaluation program after entering 
the 0PS5+ environment. Data not directly downloaded is obtained 
by user-query; responses are limited to one keystroke. Stage 1 
generates a summary report printed on user request. The Stage 2 
program, after being loaded and initialized, operates without 
intervention from the user; both a summary report and a detailed 
report are created and printed on user request. 

sops es raororyPE: 

The knowledge base for the SOPS ES prototype was developed 
using the rule-based expert system language CLIPS. All knowledge 
elements are represented in the form "IF <condition(s)> THEN 
<action(s)>." The knowledge base can be logically divided into 
sets called knowledge islands consisting of rules to diagnose a 
problem, drive the user interface, and to retrieve data specific 
to that knowledge island. A knowledge island can be modified or 
replaced to reflect a procedural change in SOPS without affecting 
the other knowledge islands; this simplifies the modification 
process. The prototype consists of four knowledge islands: Run 
Stopped Early, Data Gap Between Files, Data Coverage, and Data 
Quality. Each was implemented only to the detail required to 
realistically demonstrate the feasibility of an operational SOPS 
ES. The knowledge islands will be expanded for future implemen- 
tation to include particulars uncovered by this prototype. 

The SOPS ES prototype uses many of the standard features for 
applications running on the Apple Macintosh. The features 
include the use of multiple windows, pull-down menus, and dialog 
boxes. Dialog boxes and windows may contain buttons, scroll 
bars, or space for the analyst to type in additional information 
called a text field. Whenever possible, the ES will set a 
default value for the text fields; if the analyst changes the 
value of a text field, the ES performs a consistency check to 
prevent the entering of unacceptable values. The primary windows 
viewed by the analyst are the Transcript, Timeline, and Conclu- 
sion windows. The Transcript window maintains a log of the ES 
session containing all questions asked by the ES, the analyst's 
responses, all recommendations from the ES, and any analyst-added 
cements. The Timeline window displays the run in a graphical 
format with the ES's current focus of attention flagged. The 
Conclusion window displays the conclusions reached (rules fired) 
by the ES. All windows can be printed open completion of the ES 
session. 
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OONOUSICNS: 

The prototypes show that the expert systems offer many 
benefits. They are fast. They are consistent. The expertise of 
the nost experienced staff members is new made available to all. 
The prototypes can act as training tools when refined to a 
detailed level. Throughout development, ways in which current 
procedures could be further automated to increase accessibility 
to information, to inprove processing speed, and to decrease the 
monotony of repetitious tasks were identified. Also, areas in 
the expert systems' own operation will be streamlined to make the 
expert system concept not only workable tut operationally practi- 
cal. 


The goal of the expert system prototypes was to define the 
design and configuration of expert systems in the mi s sion 
environment. These new operational systems will be larger, more 
efficient, and more automatic, incorporating the capabilities 
indicated by, but not present in the prototypes. Both the SIPS 
and SOPS operational expert system configurations will use the 
eamo hardware, the SON 3/160 workstation, and software, dips 
with C language interfaces, for consistency and maintainability. 
Network interfaces will be established to automatically transfer 
necessary information from the existing SIPS and SOPS mainframes 
to the workstations for the expert systems' analysis. It is 
planned that this configuration will be operational by December 
1988, in biira to support ASTFD-1, the first of several scheduled 
SIDPF missions in the post-Challenger period. 
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